home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1235 < prev    next >
Text File  |  1995-07-25  |  29KB  |  675 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       J. Ioannidis
  8. Request for Comments:  1235                              G. Maguire, Jr.
  9.                                                      Columbia University
  10.                                           Department of Computer Science
  11.                                                                June 1991
  12.  
  13.  
  14.                 The Coherent File Distribution Protocol
  15.  
  16. Status of this Memo
  17.  
  18.    This memo describes the Coherent File Distribution Protocol (CFDP).
  19.    This is an Experimental Protocol for the Internet community.
  20.    Discussion and suggestions for improvement are requested.  Please
  21.    refer to the current edition of the "IAB Official Protocol Standards"
  22.    for the standardization state and status of this protocol.
  23.    Distribution of this memo is unlimited.
  24.  
  25. Introduction
  26.  
  27.    The Coherent File Distribution Protocol (CFDP) has been designed to
  28.    speed up one-to-many file transfer operations that exhibit traffic
  29.    coherence on media with broadcast capability.  Examples of such
  30.    coherent file transfers are identical diskless workstations booting
  31.    simultaneously, software upgrades being distributed to more than one
  32.    machines at a site, a certain "object" (bitmap, graph, plain text,
  33.    etc.) that is being discussed in a real-time electronic conference or
  34.    class being sent to all participants, and so on.
  35.  
  36.    In all these cases, we have a limited number of servers, usually only
  37.    one, and <n> clients (where <n> can be large) that are being sent the
  38.    same file.  If these files are sent via multiple one-to-one
  39.    transfers, the load on both the server and the network is greatly
  40.    increased, as the same data are sent <n> times.
  41.  
  42.    We propose a file distribution protocol that takes advantage of the
  43.    broadcast nature of the communications medium (e.g., fiber, ethernet,
  44.    packet radio) to drastically reduce the time needed for file transfer
  45.    and the impact on the file server and the network.  While this
  46.    protocol was developed to allow the simultaneous booting of diskless
  47.    workstations over our experimental packet-radio network, it can be
  48.    used in any situation where coherent transfers take place.
  49.  
  50.    CFDP was originally designed as a back-end protocol; a front-end
  51.    interface (to convert file names and requests for them to file
  52.    handles) is still needed, but a number of existing protocols can be
  53.    adapted to use with CFDP.  Two such reference applications have been
  54.    developed; one is for diskless booting of workstations, a simplified
  55.  
  56.  
  57.  
  58. Ioannidis & Maguire, Jr.                                        [Page 1]
  59.  
  60. RFC 1235                          CFDP                         June 1991
  61.  
  62.  
  63.    BOOTP [3] daemon (which we call sbootpd) and a simple, TFTP-like
  64.    front end (which we call vtftp).  In addition, our CFDP server has
  65.    been extended to provide this front-end interface.  We do not
  66.    consider this front-end part of the CFDP protocol, however, we
  67.    present it in this document to provide a complete example.
  68.  
  69.    The two clients and the CFDP server are available as reference
  70.    implementations for anonymous ftp from the site CS.COLUMBIA.EDU
  71.    (128.59.16.20) in directory pub/cfdp/.  Also, a companion document
  72.    ("BOOTP extensions to support CFDP") lists the "vendor extensions"
  73.    for BOOTP (a-la RFC-1084 [4]) that apply here.
  74.  
  75. Overview
  76.  
  77.    CFDP is implemented as a protocol on top of UDP [5], but it can be
  78.    implemented on top of any protocol that supports broadcast datagrams.
  79.    Moreover, when IP multicast [6] implementations become more
  80.    widespread, it would make more sense to use a multicast address to
  81.    distribute CFDP packets, in order to reduce the overhead of non-
  82.    participating machines.
  83.  
  84.    A CFDP client that wants to receive a file first contacts a server to
  85.    acquire a "ticket" for the file in question.  This server could be a
  86.    suitably modified BOOTP server, the equivalent of the tftpd daemon,
  87.    etc. The server responds with a 32-bit ticket that will be used in
  88.    the actual file transfers, the block size sent with each packet
  89.    (which we shall call "BLKSZ" from now on), and the size (in bytes) of
  90.    the file being transferred ("FILSZ").  BLKSZ should be a power of
  91.    two.  A good value for BLKSZ is 512. This way the total packet size
  92.    (IPheader+UDPheader+CFDPheader+data=20+8+12+512=552), is kept well
  93.    under the magic number 576, the minimum MTU for IP networks [7].
  94.    Note that this choice of BLKSZ supports transfers of files that are
  95.    up to 32 Mbytes in size.  At this point, the client should allocate
  96.    enough buffer space (in memory, or on disk) so that received packets
  97.    can be placed directly where they belong, in a way similar to the
  98.    NetBLT protocol [8].
  99.  
  100.    It is assumed that the CFDP server will also be informed about the
  101.    ticket so that it can respond to requests.  This can be done, for
  102.    example, by having the CFDP server and the ticket server keep the
  103.    table of ticket-to-filename mappings in shared memory, or having the
  104.    CFDP server listening on a socket for this information.  To reduce
  105.    overhead, it is recommended that the CFDP server be the same process
  106.    as the front-end (ticket) server.
  107.  
  108.    After the client has received the ticket for the file, it starts
  109.    listening for (broadcast) packets with the same ticket, that may
  110.    exist due to an in-progress transfer of the same file.  If it cannot
  111.  
  112.  
  113.  
  114. Ioannidis & Maguire, Jr.                                        [Page 2]
  115.  
  116. RFC 1235                          CFDP                         June 1991
  117.  
  118.  
  119.    detect any traffic, it sends to the CFDP server a request to start
  120.    transmitting the whole file.  The server then sends the entire file
  121.    in small, equal-sized packets consisting of the ticket, the packet
  122.    sequence number, the actual length of data in this packet (equal to
  123.    BLKSZ, except for the last packet in the transfer), a 32-bit
  124.    checksum, and the BLKSZ bytes of data.  Upon receipt of each packet,
  125.    the client checksums it, marks the corresponding block as received
  126.    and places its contents in the appropriate place in the local file.
  127.    If the client does not receive any packets within a timeout period,
  128.    it sends to the CFDP server a request indicating which packets it has
  129.    not yet received, and then goes back to the receiving mode.  This
  130.    process is repeated until the client has received all blocks of the
  131.    file.
  132.  
  133.    The CFDP server accepts requests for an entire file ("full" file
  134.    requests, "FULREQ"s), or requests for a set of BLKSZ blocks
  135.    ("partial" file requests, "PARREQ"s).  In the first case, the server
  136.    subsequently broadcasts the entire file, whereas in the second it
  137.    only broadcasts the blocks requested.  If a FULREQ or a PARREQ
  138.    arrives while a transfer (of the same file) is in progress, the
  139.    requests are ignored.  When the server has sent all the requested
  140.    packets, it returns to its idle state.
  141.  
  142.    The CFDP server listens for requests on UDP/IP port "cfdpsrv". The
  143.    clients accept packets on UDP/IP port "cfdpcln" (both to be defined
  144.    by the site administrator), and this is the destination of the
  145.    server's broadcasts.  Those two port numbers are sent to the client
  146.    with the initial handshake packet, along with the ticket.  If the
  147.    minimal ticket server is implemented as described later in this
  148.    document, it is recommended (for interoperability reasons) that it
  149.    listens for requests on UDP/IP port 120 ("cfdptkt").
  150.  
  151.    Let us now examine the protocol in more detail.
  152.  
  153. Protocol Specification
  154.  
  155.  Initial Handshake (not strictly part of the protocol):
  156.  
  157.    The client must acquire a ticket for the file it wishes to transfer,
  158.    and the CFDP server should be informed of the ticket/filename
  159.    mapping.  Again, this can be done inside a BOOTP server, a modified
  160.    TFTP server, etc., or it can be part of the CFDP server itself.  We
  161.    present here a suggested protocol for this phase.
  162.  
  163.    The client sends a "Request Ticket" (REQTKT) request to the CFDP
  164.    Ticket server, using UDP port "cfdptkt".  If the address of the
  165.    server is unknown, the packet can be sent to the local broadcast
  166.    address.  Figure 1 shows the format of this packet.
  167.  
  168.  
  169.  
  170. Ioannidis & Maguire, Jr.                                        [Page 3]
  171.  
  172. RFC 1235                          CFDP                         June 1991
  173.  
  174.  
  175.        0                   1                   2                   3
  176.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  177.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  178.       |      'R'      |      'Q'      |      'T'      |      'K'      |
  179.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  180.       |                                                               |
  181.       /                                                               /
  182.       \     Filename, null-terminated, up to 512 octets               \
  183.       /                                                               /
  184.       |                                                               |
  185.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  186.  
  187.                        Fig. 1: "ReQuest TicKet" packet.
  188.  
  189.    The filename is limited to 512 octets.  This should not cause a
  190.    problem in most, if not all, cases.
  191.  
  192.    The ticket server replies with a "This is Your Ticket" (TIYT) packet
  193.    containing the ticket.  Figure 2 shows the format of this packet.
  194.  
  195.        0                   1                   2                   3
  196.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  197.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  198.       |      'T'      |      'I'      |      'Y'      |      'T'      |
  199.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  200.       |                           "ticket"                            |
  201.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  202.       |                       BLKSZ (by default 512)                  |
  203.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  204.       |                             FILSZ                             |
  205.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  206.       |            IP address of CFDP server (network order)          |
  207.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  208.       |   client UDP port# (cfdpcln)  |   server UDP port# (cfdpsrv)  |
  209.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  210.  
  211.                     Fig. 2: "This Is Your Ticket" packet.
  212.  
  213.    The reply is sent to the UDP port that the RQTK request came from.
  214.    The IP address of the CFDP server is provided because the original
  215.    handshake server is not necessarily on the same machine as the ticket
  216.    server, let alone the same process.  Similarly, the cfdpcln and
  217.    cfdpsrv port numbers (in network order) are communicated to the
  218.    client.  If the client does not use this ticket server, but rather
  219.    uses BOOTP or something else, that other server should be responsible
  220.    for providing the values of cfdpcln and cfdpsrv.  The ticket server
  221.    also communicates this ticket/filename/filesize to the real CFDP
  222.    server.  It is recommended that the ticket requests be handled by the
  223.  
  224.  
  225.  
  226. Ioannidis & Maguire, Jr.                                        [Page 4]
  227.  
  228. RFC 1235                          CFDP                         June 1991
  229.  
  230.  
  231.    regular CFDP server, in which case informing the CFDP server of the
  232.    ticket/filename binding is trivial (as it is internal to the
  233.    process).
  234.  
  235.    Once the client has received the ticket for the filename it has
  236.    requested, the file distribution can proceed.
  237.  
  238.  Client Protocol:
  239.  
  240.    Once the ticket has been established, the client starts listening for
  241.    broadcast packets on the cfdpcln/udp port that have the same "ticket"
  242.    as the one it is interested in.  In the state diagram below, the
  243.    client is in the CLSTART state.  If the client can detect no packets
  244.    with that ticket within a specified timeout period, "TOUT-1", it
  245.    assumes that no transfer is in progress.  It then sends a FULREQ
  246.    packet (see discussion above) to the CFDP server, asking it to start
  247.    transmitting the file, and goes back to the CLSTART state (so that it
  248.    can time out again if the FULREQ packet is lost).  Figure 3 shows the
  249.    format of the FULREQ packet.
  250.  
  251.        0                   1                   2                   3
  252.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  253.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  254.       |                           "ticket"                            |
  255.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  256.       |                           checksum                            |
  257.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  258.       |      'F'      |       0       |         length == 0           |
  259.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  260.  
  261.                   Fig. 3: FULREQ (FULl file REQuest) packet.
  262.  
  263.    When the first packet arrives, the client moves to the RXING state
  264.    and starts processing packets.  Figure 4 shows the format of a data
  265.    packet.
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Ioannidis & Maguire, Jr.                                        [Page 5]
  283.  
  284. RFC 1235                          CFDP                         June 1991
  285.  
  286.  
  287.        0                   1                   2                   3
  288.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  289.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  290.       |                           "ticket"                            |
  291.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  292.       |                           checksum                            |
  293.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  294.       |          block number         |          data length          |
  295.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  296.       |                                                               |
  297.       /                                                               /
  298.       \      up to BLKSZ octets of data                               \
  299.       /                                                               /
  300.       |                                                               |
  301.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  302.  
  303.                              Fig. 4: Data Packet
  304.  
  305.    The format is self-explanatory.  "Block number" the offset (in
  306.    multiples of BLKSZ) from the beginning of the file, data length is
  307.    always BLKSZ except for the very last packet, where it can be less
  308.    than that, and the rest is data.
  309.  
  310.    As each packet arrives, the client verifies the checksum and places
  311.    the data in the appropriate position in the file.  While the file is
  312.    incomplete and packets keep arriving, the client stays in the RXING
  313.    state, processing them.  If the client does not receive any packets
  314.    within a specified period of time, "TOUT-2", it times out and moves
  315.    to the INCMPLT state.  There, it determines which packets have not
  316.    yet been received and transmits a PARREQ request to the server.  This
  317.    request consists of as many block numbers as will fit in the data
  318.    area of a data packet.  If one such request is not enough to request
  319.    all missing packets, more will be requested when the server has
  320.    finished sending this batch and the client times out.  Also, if the
  321.    client has sent a PARREQ and has not received any data packets within
  322.    a timeout period, "TOUT-3", it retransmits the same PARREQ.  Figure 5
  323.    shows the format of the PARtial REQuest packet.
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Ioannidis & Maguire, Jr.                                        [Page 6]
  339.  
  340. RFC 1235                          CFDP                         June 1991
  341.  
  342.  
  343.        0                   1                   2                   3
  344.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  345.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  346.       |                           "ticket"                            |
  347.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  348.       |                           checksum                            |
  349.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  350.       |      'P'      |       0       |      data length (2*N)        |
  351.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  352.       |           Block #0            |           Block #1            |
  353.       |           Block #2            |           Block #3            |
  354.       /                                                               /
  355.       \      data  (block numbers requested)                          \
  356.       /                                                               /
  357.       |           Block #N-2          |           Block #N-1          |
  358.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  359.  
  360.                 Fig. 5: PARREQ (PARtial file REQuest) packet.
  361.  
  362.    When all packets have been received the client enters the CLEND state
  363.    and stops listening.
  364.  
  365.    Figure 6 summarizes the client's operations in a state diagram.
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Ioannidis & Maguire, Jr.                                        [Page 7]
  395.  
  396. RFC 1235                          CFDP                         June 1991
  397.  
  398.  
  399.                            +-----------+
  400.                            |  CLSTART  |
  401.                            |           | <---.
  402.                            |   send    |     | timeout TOUT-1
  403.                            |  FULREQ   | ----'
  404.                            |           |
  405.                            +-----------+
  406.                                  |
  407.              received packet     | received packet
  408.       .-----------------------.  |
  409.       |                       V  V
  410.      +---------+             +---------+
  411.      | INCMPLT |             |  RXING  |
  412.      |         |   timeout   |         | <---.
  413.      |  send   |<------------| process |     | received packet
  414.      | PARREQ  |    TOUT-2   | packet  | ----'
  415.      |         |             |         |
  416.      +---------+             +---------+
  417.         ^   |                     |
  418.         |   |                     |finished
  419.         `---'                     |
  420.        timeout                    V
  421.         TOUT-3               +---------+
  422.                              |  CLEND  |
  423.                              +---------+
  424.  
  425.                 Fig. 6: Client State Transition Diagram
  426.  
  427.  Server Protocol:
  428.  
  429.    As described above, the CFDP server accepts two kinds of requests: a
  430.    request for a full file transfer, "FULREQ", and a request for a
  431.    partial (some blocks only) file transfer, "PARREQ".  For the first,
  432.    it is instructed to start sending out the contents of a file.  For
  433.    the second, it will only send out the requested blocks.  The server
  434.    should know at all times which files correspond to which "tickets",
  435.    and handle them appropriately.  Note that this may run into
  436.    implementation limits on some Unix systems (e.g., on older systems, a
  437.    process could only have 20 files open at any one time), but that
  438.    should not normally pose a problem.
  439.  
  440.    The server is initially in the SIDLE state, idling (see diagram
  441.    below).  When it receives a FULREQ packet, it goes to the FULSND
  442.    state, whence it broadcasts the entire contents of the file whose
  443.    ticket was specified in the FULREQ packet.  When it is done, it goes
  444.    back to the SIDLE state. When it receives a PARREQ packet, it goes to
  445.    the PARSND state and broadcasts the blocks specified in the PARREQ
  446.    packet. When it has finished processing the block request, it goes
  447.  
  448.  
  449.  
  450. Ioannidis & Maguire, Jr.                                        [Page 8]
  451.  
  452. RFC 1235                          CFDP                         June 1991
  453.  
  454.  
  455.    once again back to the SIDLE state.
  456.  
  457.                      receive    +-------+    receive
  458.                 .---------------| SIDLE |---------------.
  459.                 |    FULREQ     +-------+     PARREQ    |
  460.                 |                 ^   ^                 |
  461.                 |                 |   |                 |
  462.                 V                 |   |                 V
  463.             +--------+            |   |            +--------+
  464.             | FULSND |            |   |            | PARSND |
  465.             |        |    done    |   |    done    |        |
  466.             |  send  |------------'   `------------|  send  |
  467.             | entire |                             | req'ed |
  468.             |  file  |                             | blocks |
  469.             +--------+                             +--------+
  470.  
  471.                 Fig. 7: Server State Transition Diagram
  472.  
  473. Packet Formats
  474.  
  475.    The structure of the packets has been already described.  In all
  476.    packet formats, numbers are assumed to be in network order ("big-
  477.    endian"), including the ticket and the checksum.
  478.  
  479.    The checksum is the two's complement of the unsigned 32-bit sum with
  480.    no end-around-carry (to facilitate implementation) of the rest of the
  481.    packet.  Thus, to compute the checksum, the sender sets that field to
  482.    zero and adds the contents of the packet including the header.  The
  483.    it takes the two's complement of that sum and uses it as the
  484.    checksum.  Similarly, the receiver just adds the entire contents of
  485.    the packet, ignoring overflows, and the result should be zero.
  486.  
  487. Tuneable Parameters: Packet Size, Delays and Timeouts
  488.  
  489.    It is recommended that the packet size be less than the minimum MTU
  490.    on the connected network where the file transfers are taking place.
  491.    We want this so that there be no fragmentation; one UDP packet should
  492.    correspond to one hardware packet.  It is further recommended that
  493.    the packet size be a power of two, so that offsets into the file can
  494.    be computed from the block number by a simple logical shift
  495.    operation.  Also, it is usually the case that page-aligned transfers
  496.    are faster on machines with a paged address space.  Small packet
  497.    sizes are inefficient, since the header will be a larger fraction of
  498.    the packet, and packets larger than the MTU will be fragmented.  A
  499.    good selection for BLKSZ is 512 or 1024. Using that BLKSZ, one can
  500.    transfer files up to 32MB or 64MB respectively (since the limit is
  501.    the 16-bit packet sequence number).  This is adequate for all but
  502.    copying complete disks, and it allows twice as many packets to be
  503.  
  504.  
  505.  
  506. Ioannidis & Maguire, Jr.                                        [Page 9]
  507.  
  508. RFC 1235                          CFDP                         June 1991
  509.  
  510.  
  511.    requested in a PARREQ request than if the sequence number were 32
  512.    bits.  If larger files must be transferred, they could be treated as
  513.    multiple logical files, each with a size of 32MB (or 64MB).
  514.  
  515.    Since most UDP/IP implementations do not buffer enough UDP datagrams,
  516.    the server should not transmit packets faster than its clients can
  517.    consume them.  Since this is a one-to-many transfer, it is not
  518.    desirable to use flow-control to ensure that the server does not
  519.    overrun the clients.  Rather, we insert a small delay between packets
  520.    transmitted.  A good estimate of the proper delay between two
  521.    successive packets is twice the amount of time it takes for the
  522.    interface to transmit a packet.  On Unix implementations, the ping
  523.    program can be used to provide an estimate of this, by specifying the
  524.    same packet length on the command line as the expected CFDP packet
  525.    length (usually 524 bytes).
  526.  
  527.    The timeouts for the client are harder to compute. While there is a
  528.    provision for the three timeouts (TOUT-1, TOUT-2 and TOUT-3) to be
  529.    different, there is no compelling reason not to make them the same.
  530.    Experimentally, we have determined that a timeout of 6-8 times the
  531.    transfer time for a packet works best.  A timeout of less than that
  532.    runs the risk of mistaking a transient network problem for a timeout,
  533.    and more than that delays the transfer too much.
  534.  
  535. Summary
  536.  
  537.    To summarize, here is the timeline of a sample file distribution
  538.    using CFDP to three clients.  Here we request a file with eight
  539.    blocks.  States are capitalized, requests are preceded with a '<'
  540.    sign, replies are followed by a '>' sign, block numbers are preceded
  541.    with a '#' sign, and actions are in parentheses:
  542.  
  543. SERVER       CLIENT1     CLIENT-2      CLIENT-3      comments
  544.  
  545. IDLE                                                everybody idle
  546.              CLSTART                                CL1 wants a file
  547.              <TKRQ                                  requests ticket
  548. TIYT>                                               server replies
  549.              (timeout)                              listens for traffic
  550.              <FULREQ                                full request
  551. #0           RXING                                  CL1 starts receiving
  552.              (rx 0)
  553. #1           (rx 1)      CLSTART                    CL2 decides to join
  554.                          <TKRQ
  555. #2           (rx 2)                                 SRV still sending
  556. TIYT>                                               responds to TKRQ
  557. #3           (rx 3)      (listens)                  CL2 listens
  558.                          RXING                      found traffic
  559.  
  560.  
  561.  
  562. Ioannidis & Maguire, Jr.                                       [Page 10]
  563.  
  564. RFC 1235                          CFDP                         June 1991
  565.  
  566.  
  567. #4           (rx 4)      (rx 4)        CLSTART      CL3 joins in
  568.                                        <TKRQ
  569. #5           (missed)    (rx 5)                     CL1 missed a packet
  570. TIYT>                                  (listens)
  571. #6           (rx 6)      (rx 6)        RXING        CL3 found traffic
  572.  
  573. #7           (rx 7)      (rx 7)        (rx 7)       Server finished
  574. IDLE
  575.              (wait)      (wait)        (wait)       CL1 managed to
  576.              (timeout)   (wait)        (wait)       timeout
  577.              <PARREQ[5]  (timeout)     (timeout)    CL1 blockrequests...
  578. #5           (rx 5)      <PARREQ[0123] <PARREQ[0123456] ignored by SRV
  579.              CLEND                                  CL1 has all packets
  580. IDLE                     (wait)        (wait)       CL2+3 missed #5
  581.                          (timeout)     (timeout)
  582.                          <PARREQ[0123] <PARREQ[0123456] CL2's req gets
  583. #0                       (rx 0)        (rx 0)       through, CL3 ignored
  584. #1                       (rx 1)        (rx 1)       moving along
  585. #2                       (rx 2)        (rx 2)
  586. #3                       (rx 3)        (rx 3)
  587. IDLE                     CLEND         (wait)       CL2 finished
  588.                                        (timeout)
  589.                                        <PARREQ[456]
  590. #4                                     (rx 4)
  591. #5                                     (rx 5)
  592. #5                                     (rx 6)
  593. IDLE                                   CLEND        CL3 finished
  594.  
  595. References
  596.  
  597.    [1] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, MIT, June
  598.        1981.
  599.  
  600.    [2] Finlayson, R., "Bootstrap Loading Using TFTP", RFC 906, Stanford,
  601.        June 1984.
  602.  
  603.    [3] Croft, W., and J. Gilmore, "Bootstrap Protocol", RFC 951,
  604.        Stanford and SUN Microsystems, September 1985.
  605.  
  606.    [4] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1084,
  607.        USC/Information Sciences Institute, December 1988.
  608.  
  609.    [5] Postel, J., "User Datagram Protocol", RFC 768, USC/Information
  610.        Sciences Institute, August 1980.
  611.  
  612.    [6] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
  613.        Stanford University, August 1989.
  614.  
  615.  
  616.  
  617.  
  618. Ioannidis & Maguire, Jr.                                       [Page 11]
  619.  
  620. RFC 1235                          CFDP                         June 1991
  621.  
  622.  
  623.    [7] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
  624.        Specification", RFC 791, DARPA, September 1981.
  625.  
  626.    [8] Clark, D., Lambert, M., and L. Zhang, "NETBLT: A Bulk Data
  627.        Transfer Protocol", RFC 998, MIT, March 1987.
  628.  
  629. Security Considerations
  630.  
  631.    Security issues are not discussed in this memo.
  632.  
  633. Authors' Addresses
  634.  
  635.    John Ioannidis
  636.    Columbia University
  637.    Department of Computer Science
  638.    450 Computer Science
  639.    New York, NY 10027
  640.  
  641.    EMail:  ji@cs.columbia.edu
  642.  
  643.  
  644.    Gerald Q. Maguire, Jr.
  645.    Columbia University
  646.    Department of Computer Science
  647.    450 Computer Science
  648.    New York, NY 10027
  649.  
  650.    Phone:  (212) 854-2736
  651.  
  652.    EMail:  maguire@cs.columbia.edu
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Ioannidis & Maguire, Jr.                                       [Page 12]
  675.